“Middleware” is software that connects software components or enterprise applications and provides data and services to the applications. Examples of systems connected by Middleware include, web servers, application servers, business operations, ERP (Enterprise Resource Planning) and content management systems.
The concept of “protocol-less” or protocol agnostic middleware came from years of experience of running middleware platform for large scale telecommunication integrations. In the past, it was mandatory for an application to code specific to the middleware protocol and API's for integration with a particular system or a group of integrating systems. Alternatively, bridges or custom adapters were built to make integration work for each specific individual system or application. This increased the effort and or cost of the integration and often was one of the major reasons for delay to integrate. Further, this problem would grow as the enterprises move away from centralized ERP (Enterprise Resource Planning) systems and adopt distributed SaaS (Software as a Service) model. Forcing the SaaS applications to code to one specific protocol would be cost prohibitive and challenging to manage. Moreover, the SaaS applications are run by smaller companies that may not be able to afford coding to proprietary protocols for each of the middleware systems. However, each of the SaaS applications could be expected to provide at least one or other means of integration using industry standard integration protocols.
The existing technology is capable of connecting any application, system or device to any other application, device or system. However, the existing technology requires integrating devices or systems to use the product specific APIs or integration mechanism. Consequently, the integrator needs to write connecting code in the product proprietary APIs and methods for each application or device being integrated by the existing middleware technology. This problem in the existing technology is further aggravated by the adoption of SaaS application and proliferation of IoT (Internet of Things) devices. SaaS applications are smaller but specialized solutions that are replacing monolithic ERP systems. With the diversity created by smaller SaaS applications, there is a need for integration middleware platform that supports diverse integration mechanisms or protocols right out of the box. The existing technology is prohibitively expensive and may not be fit for this kind of application landscape. The IoT space is also fast evolving, creating the challenges similar to SaaS but of much larger volume and scale.
Another problem with the existing technology is the cost of running sophisticated middleware systems. The existing technology requires specialized system administrators to monitor and manage the platform for it to run at optimal levels and ensure that the connected applications and devices are able to exchange information effectively. In addition, the cost of deployment is also high for the existing technology because of the use of older methods and technology procedures. Any time an integration service is deployed, a large number of costly software developer hours are spent in planning and deploying the integration service.
Another problem with the existing technology is the monolithic Hub and Spoke architecture of the available middleware platforms. Traditionally, the middleware is centralized. All the information or the messages flow to the central hub, are processed there and then received by the intended recipient systems. This architecture has the disadvantage that it cannot scale to the increased demand and the workload and often breaks down at the center. This architecture also cannot provide full end to end last mile guaranteed delivery and buffering and cache capability at the edge where the integrating applications start sending or receiving the data. There is a need for a distributed and federated middleware architecture that can provide last mile guaranteed delivery, cache and buffering of data at the edge in case of the intermittent connectivity, and allow for edge and the fog computing acting more like a mesh of integration fabric than a hub and spoke monolith.
In the light of the above discussion, there appears to be a need for automating the operations and the deployment process that is being followed by existing technology.